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Defending against Sequence Number Attacks 


Abstract 


This document specifies an algorithm for the generation of TCP 
Initial Sequence Numbers (ISNs), such that the chances of an off-path 
attacker guessing the sequence numbers in use by a target connection 
are reduced. This document revises (and formally obsoletes) RFC 
1948, and takes the ISN generation algorithm originally proposed in 
that document to Standards Track, formally updating RFC 793. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6528. 


Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


For a long time, the Internet has experienced a number of off-path 
attacks against TCP connections. These attacks have ranged from 
trust-relationship exploitation to denial-of-service attacks 
[CPNI-TCP]. Discussion of some of these attacks dates back to at 
least 1985, when Morris [Morris1985] described a form of attack based 
on guessing what sequence numbers TCP [RFC0793] will use for new 
connections between two known end-points. 


In 1996, RFC 1948 [RFC1948] proposed an algorithm for the selection 
of TCP Initial Sequence Numbers (ISNs), such that the chances of an 
off-path attacker guessing valid sequence numbers are reduced. With 
the aforementioned algorithm, such attacks would remain possible if 
and only if the attacker already has the ability to perform "man-in- 
the-middle" attacks. 


This document revises (and formally obsoletes) RFC 1948, and takes 
the ISN generation algorithm originally proposed in that document to 
Standards Track. 


Section 2 provides a brief discussion of the requirements for a good 
ISN generation algorithm. Section 3 specifies a good ISN selection 
algorithm. Appendix A provides a discussion of the trust- 
relationship exploitation attacks that originally motivated the 
publication of RFC 1948 [RFC1948]. Finally, Appendix B lists the 
differences from RFC 1948 to this document. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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2. Generation of Initial Sequence Numbers 


RFC 793 [RFC0O793] suggests that the choice of the ISN of a connection 
is not arbitrary, but aims to reduce the chances of a stale segment 
from being accepted by a new incarnation of a previous connection. 
RFC 793 [RFC0O793] suggests the use of a global 32-bit ISN generator 
that is incremented by 1 roughly every 4 microseconds. 


It is interesting to note that, as a matter of fact, protection 
against stale segments from a previous incarnation of the connection 
is enforced by preventing the creation of a new incarnation of a 
previous connection before 2*MSL have passed since a segment 
corresponding to the old incarnation was last seen (where "MSL" is 


the "Maximum Segment Lifetime" [RFC0793]). This is accomplished by 
the TIME-WAIT state and TCP’s "quiet time" concept (see Appendix B of 
[RFC1323]). 


Based on the assumption that ISNs are monotonically increasing across 
connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an 
incoming SYN segment to perform "heuristics" that enable the creation 
of a new incarnation of a connection while the previous incarnation 
is still in the TIME-WAIT state (see p. 945 of [Wright1994]). This 
avoids an interoperability problem that may arise when a node 
establishes connections to a specific TCP end-point at a high rate 
[Silbersack2005]. 


Unfortunately, the ISN generator described in [RFC0793] makes it 
trivial for an off-path attacker to predict the ISN that a TCP will 
use for new connections, thus allowing a variety of attacks against 
TCP connections [CPNI-TCP]. One of the possible attacks that takes 
advantage of weak sequence numbers was first described in 
[Morris1985], and its exploitation was widely publicized about 10 
years later [Shimomural995]. [CERT2001] and [USCERT2001] are 
advisories about the security implications of weak ISN generators. 
[Zalewski2001] and [Zalewski2002] contain a detailed analysis of ISN 
generators, and a survey of the algorithms in use by popular TCP 
implementations. 


Simple random selection of the TCP ISNs would mitigate those attacks 
that require an attacker to guess valid sequence numbers. However, 
it would also break the 4.4BSD "heuristics" to accept a new incoming 
connection when there is a previous incarnation of that connection in 
the TIME-WAIT state [Silbersack2005]. 


We can prevent sequence number guessing attacks by giving each 
connection -- that is, each four-tuple of (localip, localport, 
remoteip, remoteport) -- a separate sequence number space. Within 
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each space, the ISN is incremented according to [RFC0793]; however, 
there is no obvious relationship between the numbering in different 
spaces. 


An obvious way to prevent sequence number guessing attacks while not 
breaking the 4.4BSD heuristics would be to perform a simple random 
selection of TCP ISNs while maintaining state for dead connections 
(e.g. changing the TCP state transition diagram so that both end- 
points of all connections go to TIME-WAIT state). That would work 
but would consume system memory to store the additional state. 
Instead, we propose an improvement to the TCP ISN generation 
algorithm that does not require TCP to keep state for all recently 
terminated connections. 


3. Proposed Initial Sequence Number Generation Algorithm 
TCP SHOULD generate its Initial Sequence Numbers with the expression: 
ISN = M + F(localip, localport, remoteip, remoteport, secretkey) 


where M is the 4 microsecond timer, and F() is a pseudorandom 
function (PRF) of the connection-id. F() MUST NOT be computable from 
the outside, or an attacker could still guess at sequence numbers 
from the ISN used for some other connection. The PRF could be 
implemented as a cryptographic hash of the concatenation of the 
connection-id and some secret data; MD5 [RFC1321] would be a good 
choice for the hash function. 


The result of F() is no more secure than the secret key. If an 
attacker is aware of which cryptographic hash function is being used 
by the victim (which we should expect), and the attacker can obtain 
enough material (i.e., ISNs selected by the victim), the attacker may 
simply search the entire secret-key space to find matches. To 
protect against this, the secret key should be of a reasonable 
length. Key lengths of 128 bits should be adequate. The secret key 
can either be a true random number [RFC4086] or some per-host secret. 
A possible mechanism for protecting the secret key would be to change 
it on occasion. For example, the secret key could be changed 
whenever one of the following events occur: 


o The system is being bootstrapped (e.g., the secret key could be a 
combination of some secret and the boot time of the machine). 


o Some predefined/random time has expired. 


o The secret key has been used sufficiently often that it should be 
regarded as insecure at that point. 
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Note that changing the secret would change the ISN space used for 
reincarnated connections, and thus could cause the 4.4BSD heuristics 
to fail; to maintain safety, either dead connection state could be 
kept or a quiet time observed for two maximum segment lifetimes 
before such a change. 


It should be noted that while there have been concerns about the 
security properties of MD5 [RFC6151], the algorithm specified in this 
document simply aims at reducing the chances of an off-path attacker 
guessing the ISN of a new connection, and thus in our threat model it 
is not worth the effort for an attacker to try to learn the secret 
key. Since MD5 is faster than other "stronger" alternatives, and is 
used in virtually all existing implementations of this algorithm, we 
consider that use of MD5 in the specified algorithm is acceptable. 
However, implementations should consider the trade-offs involved in 
using functions with stronger security properties, and employ them if 
it is deemed appropriate. 


4. Security Considerations 


Good sequence numbers are not a replacement for cryptographic 
authentication, such as that provided by IPsec [RFC4301] or the TCP 
Authentication Option (TCP-AO) [RFC5925]. At best, they are a 
palliative measure. 


If random numbers are used as the sole source of the secret, they 
MUST be chosen in accordance with the recommendations given in 
[RFC4086]. 


A security consideration that should be made about the algorithm 
proposed in this document is that it might allow an attacker to count 
the number of systems behind a Network Address Translator (NAT) 
[RFC3022]. Depending on the ISN generators implemented by each of 
the systems behind the NAT, an attacker might be able to count the 
number of systems behind a NAT by establishing a number of TCP 
connections (using the public address of the NAT) and identifying the 
number of different sequence number "Spaces". [Gont2009] discusses 
how this and other information leakages at NATs could be mitigated. 


An eavesdropper who can observe the initial messages for a connection 
can determine its sequence number state, and may still be able to 
launch sequence number guessing attacks by impersonating that 


connection. However, such an eavesdropper can also hijack existing 
connections [Joncheray1995], so the incremental threat is not that 
high. Still, since the offset between a fake connection and a given 


real connection will be more or less constant for the lifetime of the 
secret, it is important to ensure that attackers can never capture 
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such packets. Typical attacks that could disclose them include both 
eavesdropping and the variety of routing attacks discussed in 
[Bellovinl1989]. 


Off-path attacks against TCP connections require the attacker to 
guess or know the four-tuple (localip, localport, remoteip, 
remoteport) that identifies the target connection. TCP port number 
randomization [RFC6056] reduces the chances of an attacker of 
guessing such a four-tuple by obfuscating the selection of TCP 
ephemeral ports, therefore contributing to the mitigation of such 
attacks. [RFC6056] provides advice on the selection of TCP ephemeral 
ports, such that the overall protection of TCP connections against 
off-path attacks is improved. 


[CPNI-TCP] contains a discussion of all the currently known attacks 
that require an attacker to know or be able to guess the TCP sequence 
numbers in use by the target connection. 
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Appendix A. Address-Based Trust-Relationship Exploitation Attacks 


This section discusses the trust-relationship exploitation attack 
that originally motivated the publication of RFC 1948 [RFC1948]. It 
should be noted that while RFC 1948 focused its discussion of 
address—based trust-relationship exploitation attacks on Telnet 
[RFC0854] and the various UNIX "r" commands, both Telnet and the 
various "r" commands have since been largely replaced by secure 
counterparts (such as SSH [RFC4251]) for the purpose of remote login 
and remote command execution. Nevertheless, address-based trust 
relationships are still employed nowadays in some scenarios. For 
example, some SMTP [RFC5321] deployments still authenticate their 
users by means of their IP addresses, even when more appropriate 
authentication mechanisms are available [RFC4954]. Another example 
is the authentication of DNS secondary servers [RFC1034] by means of 
their IP addresses for allowing DNS zone transfers [RFC5936], or any 
other access control mechanism based on IP addresses. 


In 1985, Morris [Morris1985] described a form of attack based on 
guessing what sequence numbers TCP [RFC0793] will use for new 
connections. Briefly, the attacker gags a host trusted by the 
target, impersonates the IP address of the trusted host when talking 
to the target, and completes the three-way handshake based on its 
guess at the next ISN to be used. An ordinary connection to the 
target is used to gather sequence number state information. This 
entire sequence, coupled with address-—based authentication, allows 
the attacker to execute commands on the target host. 


Clearly, the proper solution for these attacks is cryptographic 
authentication [RFC4301] [RFC4120] [RFC4251]. 


The following subsection provides technical details for the trust- 
relationship exploitation attack described by Morris [Morris1985]. 


A.1. Blind TCP Connection-Spoofing 


In order to understand the particular case of sequence number 
guessing, one must look at the three-way handshake used in the TCP 
open sequence [RFC0793]. Suppose client machine A wants to talk to 
rsh server B. It sends the following message: 


A->B: SYN, ISNa 


That is, it sends a packet with the SYN ("synchronize sequence 
number") bit set and an initial sequence number ISNa. 
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B replies with 
B->A: SYN, ISNb, ACK (ISNa) 


In addition to sending its own ISN, it acknowledges A’s. Note that 
the actual numeric value ISNa must appear in the message. 


A concludes the handshake by sending 
A->B: ACK(ISNb) 


RFC 793 [RFC0O793] specifies that the 32-bit counter be incremented by 
1 in the low-order position about every 4 microseconds. Instead, 
Berkeley-derived kernels traditionally incremented it by a constant 
every second, and by another constant for each new connection. Thus, 
if you opened a connection to a machine, you knew to a very high 
degree of confidence what sequence number it would use for its next 
connection. And therein lied the vulnerability. 


The attacker X first opens a real connection to its target B -- say, 
to the mail port or the TCP echo port. This gives ISNb. It then 
impersonates A and sends 


Ax->B: SYN, ISNx 
where "Ax" denotes a packet sent by X pretending to be A. 
B’s response to X’s original SYN (so to speak) 
B->A: SYN, ISNb’, ACK (ISNx) 


goes to the legitimate A, about which more anon. X never sees that 
message but can still send 


Ax->B: ACK(ISNb’ ) 


using the predicted value for ISNb’. If the guess is right -- and 
usually it will be, if the sequence numbers are weak -- B’s rsh 
server thinks it has a legitimate connection with A, when in fact X 
is sending the packets. X can’t see the output from this session, 
but it can execute commands as more or less any user -—- and in that 
case, the game is over and X has won. 


There is a minor difficulty here. If A sees B’s message, it will 
realize that B is acknowledging something it never sent, and will 
send a RST packet in response to tear down the connection. However, 
an attacker could send the TCP segments containing the commands to be 
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executed back-to-back with the segments required to establish the TCP 
connection, and thus by the time the connection is reset, the 
attacker has already won. 


In the past, attackers exploited a common TCP implementation bug 
to prevent the connection from being reset (see subsection "A 

Common TCP Bug" in [RFC1948]). However, all TCP implementations 
that used to implement this bug have been fixed for a long time. 


Appendix B. Changes from RFC 1948 
o This document is Standards Track (rather than Informational). 
o Formal requirements [RFC2119] are specified. 


O The discussion of address—based trust-relationship attacks has 
been updated and moved to an appendix. 


o The subsection entitled "A Common TCP Bug" (describing a common 
bug in the BSD TCP implementation) has been removed. 
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